home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 359 < prev    next >
Text File  |  1994-08-27  |  4KB  |  128 lines
  1. Subject: Digested
  2. Date: Wed, 08 Jun 1994 16:12:38 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6.  
  7. Annius:
  8. > [key:action rather than action:key]
  9.  
  10. I don't see a clear advantage in either method, but I suspect action:key
  11. is best, since it is uniform.  For example, if an application called READER
  12. has three features "Open", "Close", "Quit", then it has three things to
  13. find matches for:
  14.  
  15.     Reader.Open.Key
  16.     Reader.Close.Key
  17.     Reader.Quit.Key
  18.  
  19. and it simply matches them against each line in the APPL-DEF.SYS file.
  20.  
  21. However, with key:action, what is it meant to do?  It would have to search
  22. for matches using some sort of wildcard (in the search string!):
  23.  
  24.     Reader.Open.Key.*
  25.     Reader.Close.Key.*
  26.     Reader.Quit.Key.*
  27.  
  28. then look at the last part of the matched string!
  29.  
  30. This is very different from Xdefaults, and very complicated.  The idea
  31. of Xdefaults is that an application gives a full string (like
  32. Reader.Quit.Key), and the defaults manager provides the righthand-string
  33. which matches it.  It's not only for keys, it could be anything.
  34.  
  35. An advantage of action:key is that the key can be specified using
  36. multiple notations.  eg. user could use scancodes of THEIR MACHINE.  
  37.  
  38.     *.SaveAs: 0x87001994
  39.  
  40. > 'The other way round' also provides a way of definining other things than
  41. > key shortcuts,  such as interface appearance and what have we.
  42.  
  43. Which way?  action:key does, not key:action...
  44.  
  45. action:key:
  46.  
  47.     *Dialog*.Confirm.Key: Return
  48.     *Dialog*.Confirm.Colour: Green
  49.  
  50.  
  51. key:action:
  52.     Dialog*Key.Return: Confirm
  53.     Dialog*Colour.Green: Confirm
  54.     # huh?
  55.  
  56. An advantage of key:action is that it allows multiple keys for the same
  57. action:
  58.  
  59.     Dialog*Key.Return: Confirm
  60.     Dialog*Key.Ctrl-Y: Confirm
  61.  
  62. ... but how do you show that in a menubar anyway!
  63.  
  64.  
  65. I now have no qualms about ^A or whatever.  An app which uses this simple
  66. APPL-DEF.SYS file will be configurable to whatever the user wants.  We still
  67. need a std set of key bindings... they will be the std APPL-DEF.SYS file,
  68. but it's now possible to please all the people all the time.
  69.  
  70.  
  71. Annius:
  72. > *active-window*.*key*.*ctl-w:           Close
  73. > *top-window*.*key*.*ctl-u:              Close
  74. > 
  75. > Hm.  There should be a way for a program that does NOT support the distinction
  76. > active/top to find both of these entries.   Warwick,  any suggestions?
  77.  
  78. Just a problem with key:action.  Use:
  79.  
  80. *close*.key:                     ctl-u
  81. *close-active*.key:              ctl-w
  82.  
  83. This brings up the issue of order of patterns.  I suggest we adopt the
  84. Xdefaults method whereby each line overrides previous lines.  This allows
  85. the user to continously refine their environment by adding to the end
  86. of the APPL-DEF.SYS file.  In implementation, the app just scans form
  87. beginning to end, applying each pattern.
  88.  
  89.  
  90. Michel Forget:
  91. >Annius:
  92. >[> *active-window*.*key*.*ctl-w:                Close
  93. >[> *top-window*.*key*.*ctl-u:           Close
  94. >
  95. >[Annius goes on to explain the details.]
  96. >
  97. >Annius, I feel that this is too specific.  Making a distiction between
  98. >the top window and the active window only applies to Edith.  No other
  99. >program I have seen (ever) have made this distiction.
  100.  
  101. Michel misunderstands the purpose of the appl-def.sys file.  In this file,
  102. all bindings are defined, even masterbrowse.pipe-through-Jive.key.
  103. Applications supporting appl-def.sys will include a file like this:
  104.  
  105. # Standard bindings:
  106. *close...
  107. ...
  108.  
  109. and a file like this:
  110.  
  111. # TurboFooWriter bindings:
  112. TurboFooWriter.enter-blitz-mode.key: ctrl-A
  113. ...
  114.  
  115.  
  116. The installation process will search for a appl-def.sys file.  If not found,
  117. it copies the standard bindings in.  It appends the app bindings.  All done.
  118.  
  119. The user may then use a Defaults Manager to edit anything they dislike,
  120. including removing the `TurboFooWriter.enter-blitz-mode.key' definition
  121. because they already have `*.enter-blitz-mode.key' from another piece
  122. of software they installed.
  123.  
  124.  
  125. --
  126. Warwick
  127.  
  128.